This section feels very repetitive with the "Immediate Benefits for Tool Developers" section, can they be consolidated or remove this section if it's redundant?

ack

The current experimental field is named _tags, plural

fixed.

nit: indentation

nice catch!

ACK

This one feels pretty tentative to me. IMO "Future directions" don't need to be planned or expected; they may never happen. But I think they should be plausible and feel like a natural evolution of the product. It's certainly subjective, but if something like this were to be added I would expect it to be part of some related tool rather than an evolution of Swift Testing itself. If you agree, I'd suggest removing this bullet

Not sure I completely agree. I feel the Bug trait quite "limiting" in terms of name as I may want to add a trait that indicates what "Issues" a test validate/verifies. So, I can see something like .issue(issueId:relationship:) trait that could looks something like this:

@Test(
    .issue(https://github.com/organization/project/issue/123456", relationship: .verifies),
)

I understand the name .issue may be contentious as it is likely to collide with Issue representing an Test "issue", but all this to say I would like to see an evolution to the Bug trait such that it becomes a subset of this envisioned Issue (name TBD) trait.

I actually ended up removing this and the Performance analytics bullet.

Fields are only included when the test actually uses the corresponding traits

The word "uses" is a bit confusing to me, since some traits can be applied to a test but may not be used by that test in any meaningful way. I think a better word choice would be "applied" or "applied to", as in:

Reviewing the subsequent bullets, I think this section could become a (shorter) paragraph without a title:

The field corresponding to each trait is only included for a given test conditionally, if the
trait has been applied to the test.

Updates the bulltet point and removed the "paragraph section"

This bullet doesn't seem to add much to the previous one, especially if you take my suggestion.

Plus, I don't know of a way to specify an "empty" version of any of these traits; they all require at least one value (at least one tag, for example)

makes sense, I removed it.

I think it's the versioning of the event stream which ultimately preserves backwards compatibility; clients that need to maintain compatibility can choose to continue using an older version until they're ready to upgrade.

I commented separately, but I think this bullet could be removed and you could consolidate this group of bullets into a sentence

ack

I think this proposal should clearly specify what format the string representation of each tag will have in the JSON. For example, consider this test:

@Test(.tags(.foo, .MyTagGroup.bar, .MyTagGroup.Subgroup.baz))
func example() { ... }

It has three tags of varying styles: .foo, .MyTagGroup.bar, and .MyTagGroup.Subgroup.baz. The handling of the leading period (.) character can sometimes be an important detail to specify and establish clarity around because in order for a supporting tool to integrate properly, it may need to precisely align these representations. There can also sometimes be odd details to contend with: it's technically valid syntax to have extraneous whitespace or /* ... */ comments between the tag components, for example.

There are several potential ways one could represent these different tags in the JSON: as a flattened string, with or without leading period, or decomposed into discrete "component" arrays perhaps. There are pros/cons to each approach.

I recommend you include a code example of tags, and the other traits, in this proposal, and also include an example of precisely how those traits would be represented in the JSON. And for tags specifically, I would be more verbose about the handling of the period separator in this bullet and also in the BNF-formatted JSON grammar. (That will require settling on an answer to the question above.)

I augmented the BNF output and included a sample JSON.

I did not explicitly mention the "." in the tag name, though it should be clear with the updated BNF.

This section doesn't feel like a specific "future direction" to me. It feels more like a justification for the proposal, but the Motivation section already gets to that

ack

nit: The extra empty newline isn't necessary, is it?

done

After having reviewed the proposal in detail now, I think the title could be more clear. It seems like the focus is adding a representation of three built-in traits to the event stream JSON. I'm going to suggest a title below. Feel free to consider it a starting point and edit/refine further, but I'll explain why I prefer it below:

This suggested title:

• Uses the word "include" to signify that it's adding content, rather than "enhance". (We could choose the verb "add", instead.)
• Lists the specific things it's including (luckily, the words are fairly short) and prefers that over less precise words like "Rich Test Metadata" which is more open to interpretation (what qualifies as 'rich'?).
• Omits the product name ("Swift Testing"); the ST-NNNN prefix will convey that already.
• Avoids the word ABI; I think the event stream JSON is what is being supplemented; the binary interface (ABI) of the library isn't being modified. (I chose to omit the word 'JSON'; I briefly added it at the end of my suggested title, and you could add it back if you prefer.)

ACK